@TysonAndre, please check the failing ext/standard/tests/class_object/get_object_vars_variation_004.phpt; maybe only the test expection needs to be updated.

please check the failing ext/standard/tests/class_object/get_object_vars_variation_004.phpt; maybe only the test expection needs to be updated.

That's expected - var_dump was using the gc flags on the object to detect infinite recursion, and json_encode is now using the gc flags on the object to detect infinite recursion.

The intent of get_object_vars_variation_004.phpt looks like it's to check that the right property fields are exported in get_object_vars, for properties with names that resemble protected/private properties that are not actually protected/private properties dd9ad09

I guess that this change would also mean that calling var_export($this, true) inside of jsonSerialize would now report recursion, but think most use cases wouldn't do anything along those lines, and the var_export/print_r format doesn't seem that useful to jsonSerialize

#define GC_PROTECTED                (1<<5) /* used for recursion detection */

If this or other refactorings in 8.3-dev affect major frameworks, there's the option to track infinite recursion for json_decode separately from var_export by using a different flag bit

So this is actually not a new idea (read https://bugs.php.net/bug.php?id=81524 ). The problem is obviously that you break this (which I tried with your patch and it's really broken):

class X implements JsonSerializable {
    public $prop = "value";
    public function jsonSerialize(): mixed {
        var_dump($this);
        return ['p' => $this->prop];
    }
}

echo json_encode(new X())

Basically there are for sure users that use var_dump($this) inside jsonSerialize (just for the debugging sake for example) so this would be immediately reported as a bug.

@nikic tried to handle it here #7589 but it was too slow. You could maybe try his suggestion in #7589 (comment) :

switch to a two-level recursion protection: The first user can make use of the GC_PROTECTED flag, while a nested second user would fall back to an HT instead. This would ensure that there is both little performance impact for the average case, and that there is no interference between different recursers. This would be a more intrusive change that needs to cover other users of GC_PROTECTED as well though.

@nikic tried to handle it here #7589 but it was too slow.

I hadn't seen that before. I wasn't clear on the expected behavior for var_dump - you'd have similar issues with __debugInfo and var_export, but since there are users that want this I'll avoid merging this

#define GC_PROTECTED (1<<5) /* used for recursion detection */
If this or other refactorings in 8.3-dev affect major frameworks, there's the option to track infinite recursion for json_decode separately from var_export by using a different flag bit

I see that was also mentioned in a comment there. #7589 (comment) was discouraged since using a bit flag just for json seemed excessive

That PR was using pointers as hash buckets directly, which leads to a lot of hash collisions (e.g. being aligned to 16 bytes in practice would mean all values would be hashed to the same 1 in 128 hash buckets 1 in 16 - (low bits of pointers are to bytes))

This was addressed by 53aa53f